Apparatus and method for performing integrity checks on sofware

ABSTRACT

An apparatus and method are provided for performing integrity checking of software code executing on a processing unit of the apparatus. The apparatus further includes debug logic used when debugging program code executed by the processing unit, and trusted logic for performing trusted integrity checking operations on less-trusted program code executed by the processing unit. The debug logic has an interface via which the trusted logic can program one or more control registers, that interface not being accessible by the less-trusted program code. The trusted logic programs the control registers so as to cause the debug logic to be re-used to detect one or more activities of the processing logic during execution of the less-trusted program code, and the trusted integrity checking operations performed by the trusted logic are influenced by the activities detected by the debug logic. Such an approach has been found to provide an efficient and secure technique for performing run-time integrity checking of program code.

FIELD OF THE INVENTION

The present invention relates to an apparatus and method for performingintegrity checks on software, and in particular to techniques forperforming run-time integrity checking of such software whilst it isexecuting.

BACKGROUND OF THE INVENTION

Integrity checking of software is a technique used to implement securitycountermeasures. The actual checks performed can take a variety offorms, but the aim of such checks is to ensure that the software codethat is executing is that which is expected (i.e. it has not beentampered with), and that that code is being called in the proper manner(i.e. the code around the area(s) being checked has not been tamperedwith). In particular, run-time integrity checking of code guards againstmalicious modification of code or data by internal attacks (i.e.exploiting software faults) or external attacks (i.e. hardware attacks).

One type of integrity checking procedure involves performing staticcryptographic hashes of regions of code being executed. If a code regionis tampered with then it will not produce the same cryptographic hashwhen it is next checked, indicating that something is wrong. Anothertype of integrity checking procedure involves dynamic “semantic” (alsoknown as “heuristic”) checks of key points in the code being executed.If code is used out of sequence, or in an atypical manner, then semanticchecks can be used to detect this and take appropriate action. Yetanother type of integrity checking procedure that can be performed isfunction gating, where the software (or individual functions thereof)can only be accessed through one or more predefined entry points orgates. If a function is entered without coming through the appropriategate, an error has occurred, and can be trapped in the software orhardware. Some function gate techniques require support in the corehardware (x86 has some support for creating these), whilst others can beconstructed in software.

Current implementations of integrity checking techniques are either doneentirely in software, or require custom hardware blocks external to theprocessing unit executing the code being checked. Existing software-onlyapproaches to run-time integrity checking require invasive changes tothe software being checked, which it is impossible to ensure thesecurity of (since hacked software cannot check itself), and highbandwidth cryptographic hashes of critical code running. Since thesoftware executing the hash checking has no idea which critical piece ofcode is going to run next, it has to check everything in a statisticalfashion, either resulting in a system with poor performance (due tochecking too much or checking too often), or a system with weakersecurity (due to checking less often or checking less code to reduceperformance overhead).

Considering the alternative option of using custom hardware outside ofthe processing unit executing the code, such an approach is expensive toimplement, may have restricted configurability, and will not typicallyhave access to signals internal to the processing unit to enable astrong, robust check to be performed.

From the above discussion, it will be appreciated that run-timeintegrity checking in a secure manner is difficult to achieve, and oftenrelies on custom hardware, or hard to enforce software policies.Accordingly, it would be desirable to provide an improved technique forperforming run-time integrity checking of code being executed by aprocessing unit of a data processing apparatus.

SUMMARY OF THE INVENTION

Viewed from a first aspect, the present invention provides a dataprocessing apparatus comprising: a processing unit operable to executeprogram code; debug logic for use when debugging the program codeexecuted by the processing unit; trusted logic operable to performtrusted integrity checking operations on less-trusted program codeexecuted by the processing unit; the debug logic having an interface viawhich one or more control registers associated with the debug logic areprogrammable by the trusted logic, the interface not being accessible bythe less-trusted program code; the trusted logic being operable toprogram the one or more control registers to cause the debug logic to bere-used to detect one or more activities of the processing logic duringexecution of said less-trusted program code; the trusted integritychecking operations performed by the trusted logic being influenced bythe activities detected by the debug logic.

In accordance with the present invention, debug logic already providedwithin the data processing apparatus for debugging program code executedby the processing unit is re-used to detect one or more activities ofthe processing logic during execution of certain less-trusted programcode, with the activities detected by the debug logic then being used toinfluence trusted integrity checking operations performed by the dataprocessing apparatus. In particular, trusted logic is provided toperform trusted integrity checking operations on less-trusted programcode executed by the processing unit, and the debug logic is providedwith an interface through which one or more control registers can beprogrammed by the trusted logic, that interface not being accessible bythe less-trusted program code.

It has been found that such an approach provides a much more efficientand secure technique for performing run-time integrity checking within adata processing apparatus. In particular, by re-using existing debuglogic within the data processing apparatus, the solution is relativelycheap to implement. Further, since the debug logic is programmed by thetrusted logic through an interface that is not accessible by theless-trusted program code, the integrity checking process is more securethan prior art software based solutions. Additionally, the debug logicwill typically have access to signals occurring within the processingunit, and hence can facilitate strong and robust integrity checkingprocesses.

Furthermore, as mentioned earlier, some types of integrity checkingprocedures, for example semantic checking of code, is normally performedvia invasive software patches, which malicious software can potentiallywork around. By allowing the debug hardware to monitor and detect keypoints of execution, this removes the need to invasively modify thesoftware to be monitored, thereby increasing the security, effectivenessand speed of the trusted integrity checking operations.

The trusted logic can take a variety of forms, and for example may beprovided by a separate processor to the processing unit executing theprogram code being checked. Alternatively, the trusted logic may beprovided by the processing unit itself, for example by the processingunit when operating in one or more particular privileged modes ofoperation.

As another example of how the trusted logic may be formed, one techniquethat has been developed to seek to alleviate the reliance on operatingsystem security is to provide a system in which the data processingapparatus is provided with separate domains, these domains providing amechanism for handling security at the hardware level. Such a system isdescribed for example in commonly assigned co-pending U.S. patentapplication Ser. No. 10/714,561, the contents of which are hereinincorporated by reference, this application describing a system having asecure domain and a non-secure domain. In that system, the non-secureand secure domains in effect establish separate worlds, the securedomain providing a trusted execution space separated by hardwareenforced boundaries from other execution spaces, and likewise thenon-secure domain providing a non-trusted execution space. In suchembodiments, the trusted logic may be arranged to operate in a securedomain to perform the trusted integrity checking operations.

Whilst the present invention allows the debug logic to be re-used asdescribed above, the debug logic will still typically be able to be usedfor standard debugging operations. Hence, the debug logic may forexample be accessed via one or more further interfaces by certainsoftware processes executing on the processing unit, whether trusted ornon-trusted software, or indeed by an external debugger session. In asystem employing secure and non-secure domains, this external debuggermay operate in the secure domain or the non-secure domain. In any eventthe one or more control registers controlling the re-use of the debuglogic for integrity checking purposes are only programmable by thetrusted logic via the associated interface.

There are a number of ways in which the activities detected by the debuglogic can be used to influence the trusted integrity checking operationsperformed by the trusted logic. In one embodiment, upon occurrence ofone or more predetermined conditions the debug logic is operable toissue a signal to the trusted logic to cause one or more of said trustedintegrity checking operations to be performed. In one particularembodiment, this signal will take the form of an exception signal whichtriggers the trusted logic to perform one or more trusted integritychecking operations. Hence, by such an approach, the debug logic can bearranged to immediately trigger trusted integrity checking operationsupon occurrence of one or more predetermined conditions.

These predetermined conditions can take a variety of forms. In oneembodiment, at least one of those predetermined conditions is thedetection of a predetermined activity of the processing logic by thedebug logic. Accordingly, in such instances, upon detection of certainparticularly suspect activities, the debug logic can be arranged toimmediately issue a signal to the trusted logic to invoke one or moreintegrity checking operations. As another example of the predeterminedconditions that can cause the debug logic to issue the signal, the debuglogic can be arranged to maintain information about the activitiesdetected, and one of the predetermined conditions may be the volume ofthat maintained information reaching a threshold value. Hence, in suchembodiments, the debug logic can log information about the activitiesdetected, and once that volume of information reaches a certain level,can then trigger the integrity checking operations to be performed bythe trusted logic.

There are a number of ways in which the maintained information can beused by the trusted logic. In one embodiment, the maintained informationis used by the trusted logic to determine which of the trusted integritychecking operations to perform. Alternatively, or in addition, thetrusted integrity checking operations may be performed on the maintainedinformation, rather than on the program code itself.

The debug logic can take a variety of forms. For example, in oneembodiment the debug logic may comprise one or more watchpoint registerswhich can be set to identify activities which on detection by the debuglogic should cause a signal to be issued to the trusted logic. However,in one embodiment, the debug logic comprises trace generation logic forproducing a stream of trace elements indicative of activities of theprocessing logic for use when debugging the program code executed by theprocessing logic, the trusted logic being operable to re-use the tracegeneration logic to maintain information about said one or moreactivities detected during execution of the less-trusted program code bythe processing logic, said maintained information being used toinfluence the trusted integrity checking operations performed by thetrusted logic.

Such trace logic is typically provided within a data processingapparatus to perform tracing operations when debugging the dataprocessing apparatus, such tracing operations often being referred to asnon-invasive debug operations since they do not require any modificationto the program code being executed by the processing unit. In accordancewith this embodiment of the present invention, such trace logic isre-used to detect activities, and maintain information about thoseactivities, during execution of the less-trusted program code, with theactivities to be detected being programmed into the trace logic by thetrusted logic, and with the activities detected by the trace logic thenbeing used to influence the trusted integrity checking operationsperformed by the trusted logic.

In embodiments where the debug logic comprises trace generation logic,that debug logic may further comprise a trace buffer into which themaintained information is stored. In one embodiment, this trace bufferwill be provided on the same chip as the processing unit and the debuglogic.

The maintained information can take a variety of forms. However, in oneembodiment, the maintained information comprises a log for each of theone or more activities detected. If the same type of activity isdetected multiple times, then the log for that activity may be updatedby the debug logic and that updated log may be output, for example to atrace buffer, each time it is updated, or periodically.

The activities that the debug logic may be programmed to detect can takea variety of forms. However, in one embodiment, at least one of thoseactivities comprises access by the processing logic to a specifiedmemory address range programmed into the one or more control registersby the trusted logic.

In one embodiment, the data processing apparatus has a plurality ofdomains in which devices of the data processing apparatus can execute,the processing logic being operable in a non-secure domain to executesaid less-trusted program code, and the trusted logic being operable ina secure domain to perform said trusted integrity checking operations.In one such embodiment, the processing logic is further operable in saidsecure domain, and said trusted logic is formed by said processing logicexecuting trusted integrity checking code in said secure domain.

In one such embodiment, the processing logic is operable in a pluralityof modes, including at least one non-secure mode being a mode in thenon-secure domain and at least one secure mode being a mode in thesecure domain. Typically one or more of the modes will be replicated ineach domain, and hence by way of example there may be a non-secure usermode and a secure user mode, a non-secure supervisor mode and a securesupervisor mode, etc.

Hence, whilst the secure domain and the non-secure domain provideseparate execution spaces separated by hardware enforced boundaries,different modes of operation can also be provided for the processinglogic. Such modes of operation are typically controlled by the operatingsystem applicable to the processing unit when executing in a particulardomain.

In one such embodiment, in the non-secure domain said processing logicis operable under the control of a non-secure operating system, and insaid secure domain said processing logic is operable under the controlof a secure operating system. Hence, in such embodiments differentoperating systems are used within the processing logic, dependent on thedomain that the processing logic is executing in. The secure operatingsystem will typically be significantly smaller than the non-secureoperating system and can be viewed as a secure kernel provided tocontrol certain secure functions.

In one embodiment, even where multiple domains are not used, theprocessing logic may be operable in a plurality of modes, and inparticular may operate in at least one less-trusted mode to execute theless-trusted program code, whilst the trusted logic then operates in atrusted mode to execute trusted integrity checking code. The trustedmode may take a variety of forms, but in one embodiment the trusted modeis at least one privileged mode. In such embodiments, the less-trustedmode may be a user mode, or indeed may be a less-trusted privilegedmode.

If in addition the data processing apparatus has a plurality of domainsthen in some embodiments the trusted mode may be at least one of thesecure modes associated with the secure domain. If for example thetrusted mode is a particular secure privileged mode, then theless-trusted mode in which the less-trusted program code is executed maybe a less-trusted secure mode, for example a secure user mode, oralternatively could be any of the non-secure modes, which will all beless-trusted than the secure mode. In one embodiment, the trusted logicis formed by the processing logic executing in the trusted mode, butalternatively the trusted logic may be provided by a separate processorto the processing logic.

Viewed from a second aspect, the present invention provides a dataprocessing apparatus comprising: processing means for executing programcode; debug means for use when debugging the program code executed bythe processing means; trusted means for performing trusted integritychecking operations on less-trusted program code executed by theprocessing means; the debug means having interface means via which oneor more control register means associated with the debug means areprogrammable by the trusted means, the interface means not beingaccessible by the less-trusted program code; the trusted meansprogramming the one or more control register means to cause the debugmeans to be re-used to detect one or more activities of the processingmeans during execution of said less-trusted program code; the trustedintegrity checking operations performed by the trusted means beinginfluenced by the activities detected by the debug means.

Viewed from a third aspect, the present invention provides a method ofoperating a data processing apparatus to perform integrity checkingoperations, the data processing apparatus having a processing unit forexecuting program code, and debug logic for use when debugging theprogram code executed by the processing unit, the method comprising thesteps of: employing trusted logic to perform trusted integrity checkingoperations on less-trusted program code executed by the processing unit;programming one or more control registers of the debug logic via aninterface which is not accessible by the less-trusted program code, saidprogramming causing the debug logic to be re-used to detect one or moreactivities of the processing logic during execution of said less-trustedprogram code; and performing the trusted integrity checking operationsdependent on the activities detected by the debug logic.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention will be described further, by way of example only,with reference to embodiments thereof as illustrated in the accompanyingdrawings, in which:

FIG. 1 is a block diagram of a known data processing system including anon-chip trace module;

FIG. 2 is a diagram schematically illustrating how the on-chip tracemodule and associated trace buffer can be re-used in accordance with oneembodiment of the present invention to assist in performing integritychecking operations;

FIG. 3 is a diagram illustrating in more detail the on-chip trace moduleof FIG. 2;

FIGS. 4A and 4B are flow diagrams illustrating a sequence of activitiesthat may be performed in accordance with one embodiment of the presentinvention to use the on-chip trace module to influence integritychecking operations;

FIG. 5 is a flow diagram illustrating the operation of the control logicof FIG. 3 in accordance with one embodiment of the present invention;

FIG. 6 is a flow diagram illustrating the operation of the tracegenerator of FIG. 3 in accordance with one embodiment of the presentinvention;

FIG. 7 is a diagram schematically illustrating the fields that may beprovided within each log produced by the trace generator of FIG. 3 inaccordance with one embodiment;

FIG. 8 schematically illustrates different programs operating in anon-secure domain and a secure domain;

FIG. 9 schematically illustrates a matrix of processing modes associatedwith different security domains; and

FIGS. 10 and 11 schematically illustrate different relationships betweenprocessing modes and security domains.

DESCRIPTION OF EMBODIMENTS

FIG. 1 schematically illustrates a known data processing systemproviding debug logic in the form of an on-chip trace module. Inparticular, an integrated circuit 5 such as a System-on-Chip (SoC)includes a processor core 10, a cache memory 50, an on-chip trace module70 and a trace buffer 80. Whilst in FIG. 1 the trace buffer 80 is shownas being provided on-chip, in alternative embodiments this trace bufferis provided off-chip with a bus interconnecting the trace buffer 80 withthe output from the on-chip trace module 70. Further, in someembodiments, at least part of the trace module 70 may also be providedoff-chip.

Within the processor core 10 is provided a register bank 20 containing anumber of registers for temporarily storing data. Processing logic 30 isalso provided for performing various arithmetical or logical operationson the contents of the registers. Following an operation by theprocessing logic 30, the result of the operation may be eitherrecirculated into the register bank 20 via the path 25 and/or stored inthe cache 50 over the path 27. Data can also be stored in the registers20 from the cache 50.

The SoC 5 is connected to memory 60 which is accessed when a cache missoccurs within the cache memory 50. It will be appreciated that thememory 60 may actually consist of a number of different memory devicesarranged to form a number of hierarchical levels of memory, and whilstthe memory 60 is shown as being provided off-chip, one or more of theselevels of memory may in fact be provided on-chip.

It will also be appreciated that the presence of the cache 50 isoptional, and in some implementations no cache may be present betweenthe core 10 and the memory 60.

A trace analyser 90, which may in one embodiment be formed by a generalpurpose computer running appropriate software, is coupled to the on-chiptrace module 70 and the trace buffer 80. The on-chip trace module 70 isarranged to receive via a trace interface 40 of the processor core 10information about the sequence of operations performed by the processorcore, and dependent thereon produces a stream of trace elements whichare stored in the trace buffer 80. The trace analyser 90 is then used toanalyse that stream of trace elements in order to derive informationused during debugging of the processor core. In particular, throughanalysis of the stream of trace elements, the step-by-step activity ofthe processor core can be determined, which is useful when attempting todebug sequences of processing instructions being executed by theprocessor core.

The trace analyser 90 is connected to the on-chip trace module 70 toenable certain features of the on-chip trace module to be controlled bythe user of the trace analyser. Additionally in some embodiments, thestream of trace elements produced by the on-chip trace module may beprovided directly to the trace analyser 90 rather than being buffered inthe trace buffer 80.

The above description is provided to illustrate the known use of anon-chip trace module 70 in association with a trace analyser 90 toperform debug operations on instructions executed by the processor core10. As will now be discussed in detail below, in accordance withembodiments of the present invention, the on-chip trace module isarranged to be re-used in order to assist in performing integritychecking operations of program code executed by the processor core 10.

FIG. 2 is a diagram schematically illustrating how the on-chip tracemodule and associated trace buffer can be re-used in accordance with oneembodiment of the present invention to assist in performing suchintegrity checking operations. In a similar way to the prior artdescribed with reference to FIG. 1, the SoC 100 has a processor core 140which can output signals over path 145 to debug logic 110, the debuglogic comprising on-chip trace module 120 and trace buffer 130. Inaddition, in accordance with one embodiment of the present inventiontrusted logic 150 is provided for performing trusted integrity checkingoperations on less-trusted code being run on the processor core 140. Thetrusted logic 150 is able to send signals over path 152 to an interfaceof the on-chip trace module in order to program one or more controlregisters within the on-chip trace module 120 so as to cause the on-chiptrace module to detect one or more activities of the processing logicduring execution of the less-trusted program code. The interface to theon-chip trace module via which these control registers are programmed isnot accessible by the less-trusted program code.

During running of the less-trusted code, the processor core 140 outputsin the usual way information about the sequence of operations beingperformed, which are received over path 145 by the on-chip trace module120. Dependent on how the control registers have been programmed by thetrusted logic 150, the on-chip trace module will from this informationdetect the presence of one or more activities and for each such activitywill typically generate a log providing certain details about thatactivity. This log can be maintained internally within the on-chip tracemodule 120, or be output over path 125 for storing in the trace buffer130.

On detection of certain particularly suspect activities (as defined bythe trusted logic 150) the on-chip trace module 120 may be arranged toissue an exception signal over path 122 to the trusted logic 150 tocause the trusted logic to invoke certain integrity checking operationsin respect of the code being executed on the core 140. Additionally, ifthe volume of information stored in the trace buffer 130 reaches apredetermined level, the trace buffer 130 may be arranged to issue anexception signal over path 132 to the trusted logic 150 to cause certainintegrity checking operations to be performed. In some embodiments suchan exception signal may not be issued directly by the trace buffer 130,but may be issued by the on-chip trace module 120 which can be arrangedto keep a record of how much data is in the trace buffer.

On receipt of such exception signals, the trusted logic 150 may bearranged to read the contents of the trace buffer 130 over path 134 andto use that data to either decide what integrity checking operations toperform, or indeed may perform the integrity checking operations on thatdata rather than directly on the code being run on the core 140. Basedon the results of the integrity checking operations, the trusted logicmay send certain control signals to the core 140. For example, if somesuspicious activity is detected, this may cause the processor core 140to be rebooted. Alternatively, a different action may be taken, such aswithholding certain secure services from the core 140.

In addition to reacting to exceptions issued by the debug logic 110, thetrusted logic 150 may be arranged periodically to read data out of thetrace buffer 130 and to act upon that data by performing certainintegrity checking operations.

From FIG. 2, it will be appreciated that instead of using the debuglogic 110 for its traditional purpose, namely for reference by a traceanalyser 90 during debugging operations, the same hardware logic is nowin accordance with embodiments of the present invention used by trustedlogic 150 that is used to perform trusted integrity checking operations.By appropriate programming of the on-chip trace module, this provides avery efficient and secure technique for performing run-time integritychecking of the less-trusted code executed on the core 140.

The trusted logic 150 can take a variety of forms. For example, it maybe provided by a dedicated core separate to the core 140 running theless-trusted code. Alternatively it may be provided by other dedicatedhardware logic external to the core 140. However, in an alternativeembodiment of the present invention, the trusted logic 150 is actuallyprovided by a virtual processor core executing on the same hardware asthe core 140. In particular, in one embodiment of the present invention,the chip 100 provides separate domains, with these domains providing amechanism for handling security at the hardware level. Such a system isdescribed for example in commonly assigned co-pending U.S. patentapplication Ser. No. 10/714,561 which describes a system having a securedomain and a non-secure domain. In accordance with such an approach, thenon-secure and the secure domains in effect establish separate worlds,with the secure domain providing a trusted execution space separated byhardware enforced boundaries from other execution spaces, and likewisethe non-secure domain providing a non-trusted execution space. Inaccordance with one such embodiment, the trusted logic may be formed bythe processor core when operating in the secure domain.

Irrespective of which domain the processor core is executing in, it willtypically be able to operate in a plurality of modes of operation, andmany of these modes will be replicated between the different domains.Accordingly, in the secure domain the processor core may be able tooperate in secure privileged mode, for example a secure supervisor mode,and may also be able to operate in a secure user mode. Similarly, in thenon-secure domain, the processor core may be able to operate in anon-secure privileged mode, for example a non-secure supervisor mode,and may also be able to operate in a non-secure user mode. If thetrusted logic 150 is formed by the processor core when operating in asecure privileged mode, then the less-trusted code that can be subjectedto the integrity checking operations may be executed by the processorcore when operating in any non-secure mode, or indeed by the processorcore when executing in secure user mode (or indeed any secure privilegedmode which is less trusted that the secure privileged mode in which thetrusted logic executes). Similarly, if the trusted logic is formed bythe processor core when executing in secure user mode, then theless-trusted code that can be subjected to the integrity checkingoperations may be code executed by the processor core when running inany non-secure mode.

Similarly, even in a system which does not use multiple domains, andhence in effect only has a non-secure domain, the trusted logic may beformed by the processor core when operating in a privileged mode ofoperation, and the less-trusted code may be that code executed by theprocessor core when operating in a user mode, or a less-trustedprivileged mode.

FIG. 3 is a block diagram of the on-chip trace module 120 in accordancewith one embodiment of the present invention. The on-chip trace module120 is arranged to receive over path 205 data indicative of theprocessing being performed by the processor core 140, this beingreceived over path 145 shown in FIG. 2. The sync logic 200 is arrangedto convert the incoming signals into internal versions of the signalsmore appropriate for use within the on-chip trace module 120. Theseinternal versions are then sent to the control logic 210 and the tracegeneration logic 220, although it will be appreciated that the controllogic 210 and the trace generation logic 220 will not necessarily needto receive the same signals. Fundamentally the control logic 210 needsto receive data relating to triggerable events, for example instructionaddresses, data values, register accesses, etc so that it can determinewhether the trace generator should be activated, and what types of datashould be traced. It then issues appropriate control signals to thetrace generation logic 220 to cause the required logs or trace elementsto be generated by the trace generation logic 220. The trace generationlogic 220 receives via the sync logic 200 any data that would need to betraced dependent on the control signals issued by the control logic 210.

In accordance with embodiments of the present invention, controlregisters 240 are provided which are used to configure the operation ofthe control logic 210, and to establish various flags and counters 225within the trace generator 220. These control registers are programmableby the trusted logic 150 via the interface 250, this interface beingarranged not to be accessible by any of the less-trusted code executingon the processor core. In one embodiment, the processor core is arrangedwhen outputting signals to issue a domain ID signal therewithidentifying the domain in which the processor core is operating. Thisdomain ID signal may also be referred to as the NS bit, and when the NSbit has a logic zero value this indicates that the processor core isoperating in the secure domain. In such embodiments, the interface 250can be arranged to only accept program control signals that are issuedby the processor core and are accompanied by an NS bit having a logiczero value, indicating that the processor core is operating in thesecure domain.

As also shown in FIG. 3, the trace generator 220 is able to issue anexception signal over path 227 for routing to the trusted logic 150 inorder to invoke the trusted integrity checking operations, as discussedearlier with reference to FIG. 2. Further, the trusted logic 150 canread over paths 222, 242 data held within the control registers 240and/or the flags/counters 225, which can be referenced when performingany such trusted integrity checking operations.

When the trace generator 220 determines that information in the form ofa log or one or more trace elements needs to be output to the tracebuffer, it outputs that information to the FIFO buffer 230, from whereit is then output to the trace buffer 130.

FIGS. 4A and 4B are flow diagrams illustrating the general processperformed in accordance with an embodiment of the present invention toperform trusted integrity checking operations dependent on activitiestraced by the on-chip trace module 120. In this embodiment, it isassumed that the trusted logic 150 is implemented by the processor corewhen executing in the secure domain, and in particular by the processorcore when executing in a particular secure mode of operation within thesecure domain, for example a predetermined secure privileged mode ofoperation. At step 300, the processor core boots in the secure domain,and thereafter at step 305 the processor core executing in a particularsecure mode of operation programs the on-chip trace module 120 bysending appropriate signals over path 152 to the interface 250, and fromthere to the control registers 240 of the on-chip trace module 120illustrated in FIG. 3.

In particular, in one embodiment, at step 305, the on-chip trace module120 will be programmed to identify particular regions of memory that itshould monitor for accesses to. These regions of memory may be regionscontaining instructions and/or regions containing data. For example somedata regions will contain jump tables, vector tables, and the likereferenced by the operating system, and such data regions are oftensubjected to semantic checks. Hence, the on-chip trace module may bearranged to monitor such data regions for modifications (i.e. datawrites), so that the trusted logic 150 can be alerted to such datawrites and take any appropriate action. The control registers will alsotypically include certain enable and disable registers to enable ordisable certain tracing functionality. In addition, the trusted logicmay during this programming step input data to the control registers 240which is used to set certain flags and counters 225 within the tracegenerator 220. In one embodiment, a separate flag and/or counter may beprovided in association with each region that is to be monitored. Forexample the flag/counters may be used to record/count instructionfetches in an address range, to record/count data reads in an addressrange, and/or to record/count data writes in an address range. One typeof flag that may be associated with each region to be monitored is asecurity level flag, which dependent on its setting will identifywhether accesses to the associated memory region merely need to belogged or traced, or whether instead an exception signal should begenerated immediately by the trace generation logic 220 upon detectionof an access to that memory region. Hence, by setting the security levelflag to indicate that an exception should be generated, accesses toparticularly sensitive memory regions can be alerted to the trustedlogic 150 without delay.

The counters associated with each region to be monitored may be used ina variety of ways. For example, in some situations it may be desirableto know the number of times that a particular memory region has beenaccessed, with the counter keeping track of that number, oralternatively it may be of interest only to know that the memory regionhas been accessed at all, and it may not be overly relevant how manytimes that region has been accessed. Counters can be maintained by thetrace generator 220 in order to reduce the amount of information thatneeds to be traced, for example by avoiding the need to output traceinformation each time a memory region is accessed, or by providinginformation that can enable some ordering of the information as storedwithin the trace buffer 130, for example by overwriting some previoustrace information with the updated trace information including anupdated counter value.

In addition to the control registers 240 storing information about thememory address regions to be watched, certain filters can also bespecified in the control registers to identify what subset ofinstruction and data activity is to be logged for accesses that occurwithin those memory regions, for example identifying that the programcounter (PC) source and destination should be recorded on entry to asensitive code range.

Following the programming of the on-chip trace module control registersat step 305, the processor core transfers from the secure domain/stateto the non-secure domain/state, and begins executing the less-trustedcode, in this embodiment the less-trusted code being code executed inthe non-secure domain.

At step 315, the on-chip trace module 120 determines from theinformation it receives from the processor core 140 whether an activityhas been detected which should cause trace to be triggered. Thisdecision is performed with reference to the control registers 240, andin particular the control registers identifying the memory regions ofinterest. If it is determined that trace should be triggered, then atstep 320 it is determined whether immediate generation of an exceptionis required, this being performed by the trace generator 220 withreference to the flag/counters 225. In particular, the trace generator220 references the earlier-mentioned security level flag for the memoryregion in question, the control logic 210 providing an indication of thememory region in association with the trigger signal sent from thecontrol logic to the trace generator to turn trace on.

If an immediate generation of an exception is required, the processbranches from step 320 to step 335, where the exception is generated.However, if immediate generation of an exception is not required, theprocess proceeds to step 325 where a log is generated for the memoryregion in question and sent to the FIFO 230 if appropriate. In someembodiments, the trace generator may be arranged to output the log eachtime it is updated, whereas in other embodiments the trace generator 220may be arranged to output the log only periodically.

At step 330, it is determined whether the trace buffer is more than acertain percentage full, and if not the process returns to step 315 tomonitor further activities. However, if the trace buffer is more than acertain percentage full, then the process proceeds to step 335 where anexception is generated, this exception being generated either by thetrace buffer 130 or by the on-chip trace module 120 based on itsknowledge of the contents of the trace buffer.

Thereafter the process proceeds to step 340, where the handling of theexception causes the processor core to transfer from the non-securedomain to the secure domain. Thereafter, the trusted logic 150, which inthis case is implemented by code executing in a particular secure mode,analyses the trace data by reading the required data from the tracebuffer 130 and performing certain integrity checking operations. Basedon the information contained therein, it is determined whether there hasbeen an integrity violation, and if not the process proceeds to step355, where the processor core transfers from the secure state to thenon-secure state, whereafter the process returns to step 315.

However, if at step 350 the various integrity checking operationsperformed by the trusted logic 150 when analysing the trace data at step345 indicate that there has been an integrity violation, then requiredaction is taken at step 360.

This required action can take a variety of forms. For example, for someintegrity violations, it may be appropriate to reboot the processorcore. However, for some violations, this may not be needed, and insteadthe action may involve withdrawing certain services from the processorcore. In particular, considering a processor core that can operate inthe secure domain and the non-secure domain, code executing in thesecure domain can be used to perform certain sensitive operations, withthese sensitive operations being performed as a service for certainnon-secure applications. An example of such secure operations that canbe performed in the secure domain is cryptographic key managementoperations. Such operations may be involved when performing DigitalRights Management (DRM) of media, for example music, when performingmicro-payments, when securely booting a mobile phone whilst it islogging onto a network, etc. Non-secure applications can request some ofthese operations to be performed by the secure domain on their behalf.If the integrity checking operations performed on the non-secure codeindicates that there may be an integrity violation, then one step thatcan be taken at step 360 is to withdraw such cryptographic keymanagement services from the non-secure application, thereby disablingcertain functionality.

FIG. 5 is a flow diagram illustrating the operation of the control logic210 within the on-chip trace module 120 of FIG. 3 in accordance with oneembodiment. At step 400, the control logic determines based on thesignals it receives from the sync logic 200 whether an access hasoccurred to a region of interest. As mentioned earlier, this willtypically be performed with reference to the control registers 240 thathave been programmed by the trusted logic 150. If access to a region ofinterest is determined, then the control logic 210 will assert a triggerto the trace generator 220 along with a region ID signal. Then, at step420 it is determined whether access to the region of interest hasexited, and if not the trigger continues to be asserted. However, onceaccess to the region of interest has been exited, then the trigger isde-asserted, along with de-assertion of the region ID signal, at step430. Thereafter, the process returns to step 400.

Depending on the size of the regions of interest that have been defined,it will be appreciated that the trigger may be asserted for a smallamount of time or for a relatively large amount of time. If the trustedlogic is being used to perform certain heuristic checks, then theregions defined are likely to be relatively small, for exampleidentifying only one or a few instructions in each region, andaccordingly in such instances the trigger from the control logic may beasserted for a relatively small amount of time.

FIG. 6 is a flow diagram illustrating the operation of the tracegenerator 220 of FIG. 3 in accordance with one embodiment. At step 500,it is determined whether a trigger has been asserted from the controllogic 210, and if so the process proceeds to step 505, where the flagsand counters 225 associated with the relevant region, as indicated bythe region ID signal issued by the control logic, are reviewed. Inparticular, at step 510, it is determined whether the security flag isset, and if so an exception is generated over path 227 at step 515.Thereafter, the process proceeds to step 520, or proceeds directly fromstep 510 to step 520 in the event that the security flag is not set.

At step 520, it is determined whether for the memory region in questionit is appropriate to perform a full trace or instead to generate a logof information. The information identifying whether either a full traceor a log need to be generated will in one embodiment be stored withinone of the control registers 240, or as one of the flags 225. If fulltrace is required, then the process proceeds to step 525, where one ormore trace elements are generated for outputting to the FIFO 230, thesetrace elements providing details of the activity being performed by theprocessor core. These generated trace elements are output to the FIFO atstep 530, whereafter the process returns to step 500.

However, if at step 520 it is determined that a full trace is notrequired, then the process proceeds to step 535 where a log is generatedfor the region in question. This log may take a variety of forms, andindeed one form of log will be discussed further later with reference toFIG. 7. The purpose of the log is to provide certain key informationabout the activities in respect of the memory region in question whichcan later be used to influence the integrity checking operationsperformed by the trusted logic. A separate log may be generated for eachaccess, or instead a log may be updated each time an access to aparticular region occurs, with the updated log superseding anypreviously generated version. As mentioned earlier, when updating logs,the updated log may be output each time to the FIFO 230 and from thereto the trace buffer, with the trace buffer then overwriting a previousversion of the log within the trace buffer, or alternatively the updatedlog may be retained within the trace generator 220 (for example byupdating the flags and/or counters 225, and optionally also the controlregisters 240) and only output periodically to the FIFO 230 and tracebuffer 130. Accordingly, at step 540, it is determined whether thegenerated/updated log should be output, and if not the process returnsdirectly to step 500. However, if it is determined that the log shouldbe output, then that log is output to the FIFO 230 at step 550.Thereafter the process returns to step 500.

As an example of where the full trace option indicated by steps 525, 530may be used, such an approach may be appropriate for memory regionaccesses that are of interest to dynamic semantic/heuristic checks. Itwill be appreciated that the trace elements generated at step 525 can begenerated using standard trace generation techniques, and may employ oneor more known trace compression techniques.

The alternative approach of generating a log for the particular regionaccessed will often be appropriate for access to memory regions that areused for static cryptographic hashing checks, although indeed such logsmay also be used for accesses to memory regions used for thesemantic/heuristic checks.

FIG. 7 illustrates an example of a log that may be generated for eachmemory region being monitored. The log 560 will contain a number offields, and may for example contain a field 570 identifying the size ofthe log. Alternatively, if all logs generated are of the same size, thenthis field may be omitted. An additional field 575 identifies the regionidentifier, and hence associates the log with a particular memory regionbeing accessed. The further field 580 then indicates the current accesscount as maintained by the counter 225 for the appropriate memoryregion, and field 585 provides the current state of the flags 225associated with that memory region. As mentioned earlier, one such flagwill be the security level flag, which enables just-in-time checking tobe performed by causing accesses to particularly sensitive memoryregions to be alerted to the trusted logic 150 without delay. Thesecurity flag could be analysed in combination with some form ofcounter, so that for example an exception is triggered only once everyn-th access, rather than on every access. As will be understood by thoseskilled in the art, the exact choice of flags used will depend on thetype of checking being performed, and hence for example if advancedstatistical checking is being performed the flags will be used incombination with the counters and control registers to model thesoftware that the less-trusted mode(s) is actually executing.

Dependent on how the logs are being used, and in particular which typesof integrity checks are going to make reference to those logs, it willbe appreciated that the information maintained in the logs can bevaried. For example, for some integrity checks, it may only be necessaryto identify the first access to a memory region, and accordingly theaccess count information may not be required.

As discussed earlier, in one embodiment the processor core is operablein either a secure domain or a non-secure domain. In one suchembodiment, the processor core is operable to execute monitor code inorder to transition from one domain to another. The operation of such aprocessor core is described in detail in the earlier-mentionedco-pending U.S. patent application Ser. No. 10/714,561. FIGS. 8 to 11are provided to indicate an overview of the operation of such aprocessor core, and the reader is referred to the above-mentioned USpatent application for further details.

FIG. 8 schematically illustrates various programs running on aprocessing system having a secure domain and a non-secure domain. Thesystem is provided with a monitor program 620 which executes at leastpartially in a monitor mode. The monitor program 620 is responsible formanaging all changes between the secure domain and the non-secure domainin either direction. From a view external to the core the monitor modeis always secure and the monitor program is in secure memory.

Within the non-secure domain there is provided a non-secure operatingsystem 610 and a plurality of non-secure application programs 612, 614which execute in co-operation with the non-secure operating system 610.In the secure domain, a secure kernel program 600 is provided, and thesecure kernel program 600 can be considered to form a secure operatingsystem. Typically such a secure kernel program 600 will be designed toprovide only those functions which are essential to processingactivities which must be provided in the secure domain such that thesecure kernel 600 can be as small and simple as possible since this willtend to make it more secure. A plurality of secure applications 602, 604are illustrated as executing in combination with the secure kernel 600.

FIG. 9 illustrates a matrix of processing modes associated withdifferent security domains. In this particular example the processingmodes are symmetrical with respect to the security domain andaccordingly mode one and mode two exist in both secure and non-secureforms.

The monitor mode has the highest level of security access in the systemand in this example embodiment is the only mode entitled to switch thesystem between the non-secure domain and the secure domain in eitherdirection. Thus all domain switches take place via a switch to themonitor mode and the execution of the monitor program 620 within themonitor mode.

FIG. 10 schematically illustrates another set of non-secure domainprocessing modes 1, 2, 3, 4 and secure domain processing modes A, B, C.In contrast to the symmetric arrangement of FIG. 9, FIG. 10 shows thatsome of the processing modes may not be present in one or other of thesecurity domains. The monitor mode 630 is again illustrated asstraddling the non-secure domain and the secure domain. The monitor mode630 can be considered a secure processing mode, since a secure statusflag may be changed in this mode. Hence, it effectively provides theultimate level of security within the system as a whole.

FIG. 11 schematically illustrates another arrangement of processingmodes with respect to security domains. In this arrangement both secureand non-secure domains are identified as well as a further domain. Thisfurther domain may be such that it is isolated from other parts of thesystem in a way that it does not need to interact with either of thesecure domain or non-secure domain illustrated.

From the above description of an embodiment of the present invention, itwill be appreciated that such embodiments make the process of run-timeintegrity checking on executing software more efficient, and in oneparticular embodiment provide a cost-effective solution by takingadvantage of a processor core's secure execution space as provided by asecure domain described earlier, along with existing core debughardware. By such an approach, efficient checking of code and data thatis being used by the processor core can be performed, either in a“just-in-time” fashion, or in a more advanced statistical mode.

Just-in-time checking is when the entering of a critical section by theless-trusted software is detected, and then a switch to the trustedintegrity checking operations takes place to perform the validation ofthe critical section before it executes. This is efficient because onlythe software that the Normal World is actually executing needs to bechecked and the rest can be ignored. Such an approach can be implementedthrough use of the earlier mentioned security level flag.

“Advanced statistical mode” checking is where the flags, counters andcontrol registers are used to model the software that the less-trustedmode(s) is actually executing, and the checks are performed in a mannerappropriate to the model.

One particular processor core which provides the earlier-mentionedsecure and non-secure domains is a core constructed using ARM Limited'sTrustZone architectural features, but it will be appreciated from theearlier discussions that embodiments of the present invention can alsobe employed in connection with other types of processor core.

In accordance with embodiments of the present invention, the on-chiptrace module is shared between the run-time integrity checking softwareand the more traditional debug agent/trace analyser tool. This sharingprocess needs to be managed, but can be designed into the trustedsoftware, allowing the run-time trusted logic to be turned off whentraditional software tracing is required. In the above describedembodiment, this would also have the consequence that security servicesrunning in the secure domain will typically stop providing thoseservices if they were relying on the run-time integrity checking toenforce some level of security in the non-trusted domain.

In accordance with the above described embodiments, the on-chip tracemodule is provided with extended configurability, extended internalfunctions, and a secure software interface. This enables trustedintegrity checking code executing in the secure domain to police theinstruction and data activity of the less-trusted code executing in thenon-secure domain. The extensions may include, but are not limited to,the addition of flags/counters to record/count instruction fetches in anaddress range, to record/count data reads in an address range, and torecord/count data writes in an address range. Further, filters can bespecified in the control registers to identify what subset ofinstruction and data activity is logged. In addition, hardware rules,which are secure-software configurable, may be applied to the aboveflags and counters in order to determine whether to trigger asecure-software exception as discussed earlier. From the earlierdiscussions, it will also be appreciated that the trusted integritychecking operation code can configure, reset and retrieve informationfrom the on-chip trace module and associated trace buffer for use inperforming the integrity checking operations on the less-trusted code.

The above features of embodiments of the present invention provide thefollowing functionality. Firstly, they can improve the robustness ofsemantic checks. Semantic checks of code are normally managed viainvasive software patches, which malicious software can work around. Byallowing the trace logic hardware to monitor and record key points ofexecution, the need to invasively modify the software being monitored isremoved. This increases the security of the system, provided access tothe on-chip trace module and associated trace buffer is only allowed bythe trusted software when it is being used for run-time integritychecking. The order of execution of code or data regions could also belogged by the trace module hardware, and hence the less-trusted code canexecute at full speed despite the fact that data logging is beingperformed for semantic checking processes.

Semantic checks often apply to non-static data regions (for example jumptables or vector tables), and so the ability to monitor these regionsfor modifications is very important. The secure integrity checking codecan then take appropriate action when a bad data write to a key table isdetected.

The above features of embodiments of the present invention also provideimproved performance for static integrity checks. In particular, thetrusted integrity checking code can generate a statistical model of whathas been running in the non-secure domain, and adjust heuristicscontrolling what to check and how often it will need checking—someintegrity checking is a statistical process. This enables the softwareto reduce the overall amount of hash checking required.

Additionally, security-critical regions of code can be configured to beautomatically checked when they are entered (by use of the earliermentioned exception signals), and hence before they are executed. Thetrusted integrity checking code could apply heuristics, for exampleunder secure timer control, to enable and disable this feature to tradeoff between security and execution overhead.

The above described embodiment of the present invention is also highlyconfigurable. The trusted integrity checking code that configures thecontrol registers within the trace logic and performs the checks can bewritten to suit a specific piece of less-trusted software code, whichhence makes the overall system very configurable by the end customer.

Embodiments of the present invention also exhibit power savingadvantages over the known prior art. In particular, run-time integritychecking is a difficult process, and in typical prior art systems oftenresults in precautionary checks which may not be required. By enablingrun-time code analysis using the earlier described techniques ofembodiments of the present invention, heuristics can be applied to focuson code that is executing, thereby improving performance and reducingpower use.

Although a particular embodiment has been described herein, it will beappreciated that the invention is not limited thereto and that manymodifications and additions thereto may be made within the scope of theinvention. For example, various combinations of the features of thefollowing dependent claims could be made with the features of theindependent claims without departing from the scope of the presentinvention.

1. A data processing apparatus comprising: a processing unit operable toexecute program code; debug logic for use when debugging the programcode executed by the processing unit; trusted logic operable to performtrusted integrity checking operations on less-trusted program codeexecuted by the processing unit; the debug logic having an interface viawhich one or more control registers associated with the debug logic areprogrammable by the trusted logic, the interface not being accessible bythe less-trusted program code; the trusted logic being operable toprogram the one or more control registers to cause the debug logic to bere-used to detect one or more activities of the processing logic duringexecution of said less-trusted program code; the trusted integritychecking operations performed by the trusted logic being influenced bythe activities detected by the debug logic.
 2. A data processingapparatus as claimed in claim 1, wherein upon occurrence of one or morepredetermined conditions the debug logic is operable to issue a signalto the trusted logic to cause one or more of said trusted integritychecking operations to be performed.
 3. A data processing apparatus asclaimed in claim 2, wherein at least one of said one or morepredetermined conditions is the detection of a predetermined activity ofthe processing logic by the debug logic.
 4. A data processing apparatusas claimed in claim 2, wherein the debug logic is operable to maintaininformation about the activities detected and one of said one or morepredetermined conditions is a volume of said maintained informationreaching a threshold value.
 5. A data processing apparatus as claimed inclaim 1, wherein the debug logic is operable to maintain informationabout the activities detected, said maintained information being used bythe trusted logic to determine which of said trusted integrity checkingoperations to perform.
 6. A data processing apparatus as claimed inclaim 1, wherein the debug logic is operable to maintain informationabout the activities detected, said trusted integrity checkingoperations being performed on the maintained information.
 7. A dataprocessing apparatus as claimed in claim 1, wherein said debug logiccomprises trace generation logic for producing a stream of traceelements indicative of activities of the processing logic for use whendebugging the program code executed by the processing logic, the trustedlogic being operable to re-use the trace generation logic to maintaininformation about said one or more activities detected during executionof the less-trusted program code by the processing logic, saidmaintained information being used to influence the trusted integritychecking operations performed by the trusted logic.
 8. A data processingapparatus as claimed in claim 7, wherein said debug logic furthercomprises a trace buffer into which said maintained information isstored.
 9. A data processing apparatus as claimed in claim 7, whereinsaid maintained information comprises a log for each of said one or moreactivities detected.
 10. A data processing apparatus as claimed in claim1, wherein at least one of said one or more activities comprises accessby the processing logic to a specified memory address range programmedinto the one or more control registers by the trusted logic.
 11. A dataprocessing apparatus as claimed in claim 1, wherein the data processingapparatus has a plurality of domains in which devices of the dataprocessing apparatus can execute, the processing logic being operable ina non-secure domain to execute said less-trusted program code, and thetrusted logic being operable in a secure domain to perform said trustedintegrity checking operations.
 12. A data processing apparatus asclaimed in claim 11, wherein said processing logic is further operablein said secure domain, and said trusted logic is formed by saidprocessing logic executing trusted integrity checking code in saidsecure domain.
 13. A data processing apparatus as claimed in claim 12,wherein said processing logic is operable in a plurality of modes,including at least one non-secure mode being a mode in the non-securedomain and at least one secure mode being a mode in the secure domain.14. A data processing apparatus as claimed in claim 13, wherein in saidnon-secure domain said processing logic is operable under the control ofa non-secure operating system, and in said secure domain said processinglogic is operable under the control of a secure operating system.
 15. Adata processing apparatus as claimed in claim 1, wherein the processinglogic is operable in a plurality of modes, the processing logic beingoperable in at least one less-trusted mode to execute said less-trustedprogram code, and the trusted logic being operable in a trusted mode toexecute trusted integrity checking code.
 16. A data processing apparatusas claimed in claim 15, wherein said trusted mode is at least oneprivileged mode.
 17. A data processing apparatus as claimed in claim 15,wherein the data processing apparatus has a plurality of domains inwhich devices of the data processing apparatus can execute, saidplurality of modes comprising at least one non-secure mode being a modein the non-secure domain and at least one secure mode being a mode inthe secure domain.
 18. A data processing apparatus as claimed in claim17, wherein said trusted mode is at least one of said at least onesecure modes.
 19. A data processing apparatus as claimed in claim 18,wherein said at least one less-trusted mode comprises at least onenon-secure mode.
 20. A data processing apparatus as claimed in claim 15,wherein said trusted logic is formed by said processing logic executingin said trusted mode.
 21. A data processing apparatus as claimed inclaim 1, wherein said trusted logic is provided by a separate processorto the processing logic.
 22. A data processing apparatus comprising:processing means for executing program code; debug means for use whendebugging the program code executed by the processing means; trustedmeans for performing trusted integrity checking operations onless-trusted program code executed by the processing means; the debugmeans having interface means via which one or more control registermeans associated with the debug means are programmable by the trustedmeans, the interface means not being accessible by the less-trustedprogram code; the trusted means programming the one or more controlregister means to cause the debug means to be re-used to detect one ormore activities of the processing means during execution of saidless-trusted program code; the trusted integrity checking operationsperformed by the trusted means being influenced by the activitiesdetected by the debug means.
 23. A method of operating a data processingapparatus to perform integrity checking operations, the data processingapparatus having a processing unit for executing program code, and debuglogic for use when debugging the program code executed by the processingunit, the method comprising the steps of: employing trusted logic toperform trusted integrity checking operations on less-trusted programcode executed by the processing unit; programming one or more controlregisters of the debug logic via an interface which is not accessible bythe less-trusted program code, said programming causing the debug logicto be re-used to detect one or more activities of the processing logicduring execution of said less-trusted program code; and performing thetrusted integrity checking operations dependent on the activitiesdetected by the debug logic.